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ABSTRACT 


Increase in the demand for software, coupled with 
concerns regarding cost overruns and schedule delays in 
software development lead experts to believe that the United 
States will be unable to produce the software it needs. In 
order to improve their performance, software professionals 
must first understand the development process. The System 
Dynamics model of software project management provided a 
tool for the understanding of a single project. 

This tool was expanded to model a multiproject environ¬ 
ment in which more than one project is managed. Identifica¬ 
tion and addition of the variables necessary to reflect 
manpower decisions resulting in movement between projects 
and within an organization were effected. This enhancement 
provided insights into the allocation of resources to 
projects and into the optimization of the staffing function. 



iii 




TABLE OF CONTENTS 


I. INTRODUCTION - 1 

A. BACKGROUND- 1 

B. THESIS OBJECTIVES - 4 

C. METHODOLOGY - 5 

II. THE SYSTEM DYNAMICS MODEL OF SOFTWARE PROJECT 

MANAGEMENT - 6 

A. SYSTEM DYNAMICS - 6 

B. MODEL STRUCTURE AND BEHAVIOR - 8 

C. SUMMARY- 13 

III. EXTENSIONS TO MODEL A MULTIPROJECT ENVIRONMENT — 15 

A. EXISTING MODEL- 15 

B. MODEL EXTENSIONS - 19 

C. DESCRIPTION OF MULTIPROJECT ENVIRONMENT - 20 

IV. EXPERIMENT RESULTS - 33 

A. EXPERIMENTAL ENVIRONMENT - 33 

B. DESCRIPTION OF EXPERIMENTS - 33 

C. EXPERIMENT SET ONE- 3 5 

D. EXPERIMENT SET TWO- 48 

E. EXPERIMENT SET THREE- 86 

V. CONCLUSIONS AND SUGGESTIONS FOR FURTHER 

RESEARCH- 123 

A. CONCLUSIONS- 123 

B. SUGGESTIONS FOR FURTHER RESEARCH - 125 

APPENDIX: SUMMARY RESULTS OF EXPERIMENT SET ONE - 127 

iv 





























LIST OF REFERENCES - 

INITIAL DISTRIBUTION LIST 


134 

135 


V 




I. 


INTRODUCTION 


A. BACKGROUND 

While computer hardware productivity continues to 
improve, software productivity is unable to "hold its own." 
[Ref. l:p. 43] This is true at a time when there is an ever 
increasing demand for development and implementation of 
software applications. The demand for software will 
continue to grow at a huge rate; one estimate places that 
figure at 25 percent annually [Ref. 2:p. 31]. 

Increase in the demand for software is not the only 
problem facing the software industry. Other concerns 
include software that costs more than it is budgeted for, 
software that is delivered late or not at all, and software 
that doesn't meet user requirements. All these 
considerations lead to the concern that the United States 
will be "unable to produce the software it needs." [Ref. 
2:p. 31] 

In order to meet the demand facing the software industry 
while addressing the concerns listed above, it is necessary 
that software profess'.onals understand the software 
development process. Only after this has taken place will 
economical and timely development of software applications 
be feasible. 
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Understanding the software development process is not as 
simple as it may seem. As Roberts has pointed out [Ref. 

3:p. 293], project management techniques are often based on 
a single feedback loop, much like that illustrated in Figure 
1 [Ref. 4:p. 1427]. 


0 


SCHEOULCO COMPLETION 
DATE 


o 


RESOURCE change A 
ALLOCATION OECiSlON 


o 

PEOPLE A OTHER 
PROJECT RESOURCES 
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FORECAST completion 
DATE 


WORK RATE 

© 

REPORTED PROGRESS 


Figure 1. A Model of Software Project Management 


Actual software development processes are, however, much 
more complex and involve more interdependent, interrelated 
variables [Ref. 4:p. 1427]. A more realistic model of the 
software development process, illustrating some of these 
variables and their interdependence, is shown in Figure 2 
[Ref. 4:p. 1428]. More importantly, understanding the 
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behavior of this process and these interrelationships "is 
complex far beyond the capacity of human intuition," [Ref. 
4:p. 1428] 



Figure 2. Amendment to the Project Management 
Model 


While understanding a single project is beyond the 
capability of human beings, understanding multiple projects 
running in parallel or concurrently is even more difficult, 
^fet it is in just this situation that many organizations 
find themselves. As Archibald states, "It is rare to find a 
project that exists by itself without interaction with other 
projects." [Ref. 5;p. 59] He continues to emphasize that 



the "basic problems result from competition between... 
projects for resources...." [Ref. 5:p. 59] Most software 
organizations are in the process of developing many projects 
at any time; effective management of these projects is not 
possible without an understanding of how they are 
interrelated. 

B. THESIS OBJECTIVES 

The primary objective of this thesis is expansion of the 
human resource management subsystem of the System Dynamics 
model of software project management, presented in Reference 
4. The model will be described in depth in Chapter II. 

This expansion is to enable the model to demonstrate the 
effects of manpower decisions in a multiproject environment. 
It will allow modelling of an organization through which 
many projects are being managed at the same time. These 
projects may have different starting dates, different 
amounts of resources (time, money), and different 
characteristics (delivered source instructions). 

Through this expansion of the existing model, 
information can be gleaned in the following areas; 

1. Effects of management manpower decisions on the 
allocation of resources to different projects in a 
software development arena. 

2. Identification of the additional variables necessary 
to reflect manpower decisions resulting in movement 
between projects and within an organization. 

3. Insights to be gained on optimizing the staffing 
function in a multiproject environment. 
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C. METHODOLOGY 


Prototyping will be used in developing this thesis. 
Initially, the redesigned human resource management 
subsystem will be implemented in an existing smaller model. 
This will be an iterative process with continuing 
adaptations being made to the code as analysis of results 
indicates the necessity for these changes to make the model 
a more accurate reflection of reality. Once an acceptable 
design is achieved, it will be incorporated, along with any 
necessary adaptations, to a more detailed model. A 
description of this enhanced model can be found in Chapter 
III. Then experimentation with staffing policies will be 
conducted; results of these experiments will be presented in 
Chapter IV. 
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II, THE SYSTEM DYNAMICS MODEL OF SOFTWARE 
PROJECT MANAGEMENT 


A. SYSTEM DYNAMICS 

The software project management model which is to be 
enhanced is based on the concept of system dynamics. As 
Roberts states, "System dynamics is the application of 
feedback control systems principles and techniques to 
managerial, organizational, and socioeconomic problems," 
[Ref. 3;p. 3] The philosophy of the system dynamics 
approach is that the behavior of an organization is a 
reflection of its structure, including policies and 
traditions [Ref. 3:p. 4]. Yet another aspect of system 
dynamics is the idea that one can most effectively view 
organizations in terms of their flows (such as the flow of 
people into and out of the workforce) and the cause~and- 
effect chains which can be traced through these flows [Ref. 

3 ; p. 5 ] . 

These organizational relationships are of two types— 
levels and rates. A level represents accumulations of 
resources over time of flows or changes that come into and 
out of that level [Ref. 3;p. 195]. In the software 
development application of the svstem dynamics approach, one 
example of a level is the number of people, or workforce 
level, involved in the development of a project. A rate 
includes any "flow, decision, action, or behavior that 
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changes over time as a function of the influences acting 
upon it.” [Ref. 3:p. 19] An example of a rate in the model 
is that of assimilation rate—the rate at which workers are 
assimilated into the workforce. Modelling of these 
organizational relationships is the first step in the 
application of the system dynamics approach. 

The next step for a system dynamics project is to apply 
computer simulation techniques to the model. These 
techniques enable the user to understand the complex 
interrelationships existent in a feedback system. According 
to Roberts, a feedback system exists whenever an individual 
takes an action which will later influence other actions he 
takes [Ref. 3;p. 7]. For example, in software development, 
a project manager may decide to begin a project with only 
five programmers. This decision will affect whether the 
project remains on schedule which will in turn affect 
whether the project manager needs to hire more programmers. 
Figure 1 provides an example of a very simplistic feedback 
loop. Figure 2 portrays a feedback loop which is more 
realistic and obviously more difficult for a human being to 
comprehend. It is for this reason that computer simulation 
is necessary to reflect the interrelationships in the real 
system. 

Dynamo is the computer simulation language in which the 
software project management model was written. It is a 
computer program which is capable of executing continuous 
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simulation models. Dynamo was developed at the Sloan School 
of Management at M.I.T. in the late 1950's [Ref. 6:p. viii]. 
According to Roberts, Dynamo is "a major asset to the system 
dynamics effort.” [Ref 3:p. 5] 

B. MODEL STRUCTURE AND BEHAVIOR 

The System Dynamics model of software project management 
was developed to aid the software project manager in 
understanding the software development process and the 
dynamic behavior of a project. As previously mentioned, 
the software development process includes many complex, 
interrelated variables. Understanding and tracing the 
relationships among these variables is beyond the capability 
of human intuition [Ref. 7:p. 6]. This model provides the 
necessary information to allow human beings to view the 
results of these interrelationships and the effects of the 
many variables on each other. 

It is important to clarify two points. First, the focus 
of the model is on the aspects of the project that change 
over time such as workforce level rather than aspects which 
remain constant, such as programming language. Second, this 
model was not intended to provide ’’point-predictions.” It 
is descriptive rather than prescriptive in nature and was 
designed to be used in understanding relationships rather 
than predicting them. [Ref. 7;p. 8] 

The model integrates the multiple functions of software 
development to include both management-type functions such 
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as planning and controlling and software production-type 
functions such as coding and testing [Ref. 7:p. 6]. A 
description of how these functions are integrated will be 
presented later in this chapter. 

Finally, the model allows the manager to perform 
sensitivity analysis by changing the values of variables and 
viewing the results of these changes. This capability is 
particularly important when studying feedback systems since 
they "exhibit behavior that cannot be anticipated by 
studying the components of the system in isolation." [Ref. 
6:p. 1] The results of changing a variable cannot be 
predicted by the manage, solely on the basis of the new 
value of the variable; the model gives the manager the 
ability to see the overall results of any changes and how 
those changes affect many variables. 

The System Dynamics model of software project management 
was developed on the basis of interviews of software project 
managers in five organizations. It comprises four 
subsystems as depicted in Figure 3 [Ref. 7:p. 8a]. These 
include the human resource management subsystem, the 
software production subsystem, the controlling subsystem, 
and the planning subsystem. Some of the interrelationships 
among the four subsystems are also illustrated in Figure 3. 

A brief description of each subsystem follows. A more 
complete discussion of the model can be found in Reference 
4. 
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Figure 3. The System Dynamics Model of Software 
Project Management 


1. Human Resource Management Subsystem 

The human resource management subsystem models the 
hiring, training, assimilation, and transfer of the 
workforce. In this subsystem, a distinction is made between 
newly hired and experienced workforce, as new team members 
tend to be less productive than experienced ones. [Ref. 

2:p. 102] 

The differentiation between new and experienced 
workers also allows modelling of the training process 
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involved in assimilating new hires. As veterans train 
newcomers, this training can reduce the veterans' 
productivity which will affect the project's progress. 

[Ref. 2:p. 102] 

Several factors influence the project manager's 
decision regarding workforce size. Amongst these are the 
scheduled completion date and the workforce stability. 
Concern over workforce stability leads project managers to 
attempt to predict the project employment time for 
perspective employees before they are hired. Generally, the 
"weight the managers give to stability versus completion 
date changes as the project progresses." [Ref. 2;p. 102] 
This subsystem will be the primary area in which 
enhancements to the model will be made. Development of the 
central staffing function necessary to model the transfer of 
personnel between projects will occur in this subsystem. 

2. Software Production Subsystem 

The software production subsystem models the 
development phase, to include design, coding, and testing. 

It does not include the requirements definition phase nor 
does it include the operation and maintenance phases. 

This subsystem models productivity, defined as 
potential productivity minus the loss from faulty processes. 
Potential productivity is the maximum level of productivity 
that can be reached when a group makes best use of its 
resources. It is dependent on the nature of the task and 
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the resources available to the group. "Loss from faulty 
processes are losses in productivity from things like 
communication and coordination overhead and low motivation." 
[Ref. 2;pp. 102-103] 

3. Control Subsystem 

In all organizations, the decision makers make 
decisions based on the available information, which is often 
inaccurate. Factors such as time lag, information flow, and 
distortion cause perceived conditions to be far different 
from those actually encountered. [Ref. 2:p. 103] 

Progress rate is one example of a variable in the 
model which is difficult to measure during the project. 
Determination of a quantifiable way in which to measure 
progress is one of the greatest roadblocks to accurate 
measurement. Often when a programmer is asked to provide an 
estimate of the amount of progress, he will divide the 
amount of time he has spent on the project by the amount of 
time budgeted. The realization that his estimate is wrong 
will occur only towards the end of the project. [Ref. 2:p. 
103] 

This type of progress measurement causes status 
reporting to be an echo of original estimates, often grossly 
misstated. As the project progresses into its final phases, 
accomplishments tend to become more visible and project 
members are better able to report how productive they have 
been. [Ref. 2:p. 103] 
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4. Planning Subsystem 


In the planning subsystem, initial project estimates 
are made at the beginning of the project for various factors 
such as completion time, original staffing levels, and man- 
days reguired to complete the project. These estimates are 
revised throughout the project's life based on feedback from 
other subsystems. 

For example, if a project is perceived to be behind 
schedule, plans can be made to add more people, extend the 
project's schedule or do some of both. These types of 
decisions are motivated by variables that change dynamically 
through the project's lifecycle. One illustration of this 
occurrence has to do with staffing level. Often, management 
will respond to a project being delayed in its early stages 
by increasing the workforce. However, as time passes and it 
becomes later in the project's lifecycle, management becomes 
more and more reluctant to change the workforce. This is 
due to the realization that the time doesn't exist, prior to 
the necessary completion date, to assimilate and train these 
new people. [Ref. 4;p, 1431] 

C. SUMMARY 

In this chapter, a brief, high-level explanation of the 
System Dynamics model of software project management has 
been presented. For the interested reader, a more detailed 
description of the model can be found in Reference 4. The 
explanation presented in this chapter provides a basis for 
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This 


understanding of the extension of the model to a 
multiproject environment, the purpose of this thesis 
extension is described in the next chapter. 
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III. EXTENSIONS TO MODEL A MULTIPROJECT ENVIRONMENT 


A. EXISTING MODEL 

The System Dynamics model as described in the previous 
chapter allows simulation of one project at a time. Though 
this enables project managers and others involved in 
software development to understand the dynamics of this one 
project, it ignores the dynamics of situations involving two 
or more projects. Software organizations are often, if not 
always, involved in the development of more than one project 
or of a project with more than one component. People are 
transferred between projects or components as well as being 
hired and fired. Many variables affect management's 
decisions regarding when and how these workforce changes 
should take place. Extension of the System Dynamics model 
to enable the model to demonstrate the effects of these 
manpower decisions in a multiproject environment is the 
primary objective of this thesis. 

This extension affected primarily the human resource 
management subsystem as the movement of people with regards 
to the workforce was the point of interest. In order to 
grasp the changes made, one must first be somewhat familiar 
with the subsystem as it existed prior to enhancement. 

Recall that the human resource management subsystem is one 
of four interrelated subsystems making up the System 
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Dynamics model. This relationship is pictured in Figure 4 
[Ref. 7;p. 8a]. 



Figure 4. The System Dynamics Model of Software 
Project Management 


The human resource management subsystem models the 
movement of people into and out of the workforce. It also 
models the training and assimilation of the workforce. 
[Ref. 7:p. 102] Figure 5 illustrates the design of the 
subsystem prior to its extension [Ref. 7;p. 8b]. A more 
complete description of this subsystem and the model as a 
whole can be found in Reference 4. 
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Figure 5. The Human Resource Management Subsystem 


The schematic conventions used in Figure 5 are the 
standard conventions used in system dynamics models. 
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Constants, whose values will not change over the course of 
the simulation, are indicated by the symbol shown below: 


\ 


Variables, as discussed in Chapter II, include levels and 
rates. These are represented as shown below: 



RATE 


RATE 


The cloud-like symbols represent sources and sinks which 
indicate where resources come from and go as they flow into 
and out of levels. "For example, for a level of workforce 
these symbols represent where people come from when hired 
and where they go when leaving the project." [Ref. 7:p. 9] 
Referring back to Figure 5, one can see these symbols 
used to indicate the relationships between the variables in 
the human resource management subsystem. For instance, the 
source (the cloud-like symbol) on the left of the figure 
represents people available to be hired. They are hired by 
the organization at a certain rate (HIRERT), i.e., people 
per day. This rate is influenced by the delay in hiring 
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(HIREDY) and how many people need to be hired (WFGAP). Once 
hired, these people become part of the newly hired workforce 
(WFNEW). By tracing Figure 5 in this manner, the 
relationship between the variables in the existing human 
resource management subsystem becomes evident. 

B. MODEL EXTENSIONS 

Three changes were made to the existing model to enable 
simulation of a multiproject environment. The first and 
second of these did not involve the human resource 
management subsystem alone but rather affected the entire 
model. The first change was to modify all applicable 
variables so that they represented arrays. The addition of 
arrays enabled appropriate variables to be applied to both 
projects (the completed extension to the model permits 
simulation of two projects at the same time). This 
capability reduced greatly the need for redundant program 
code. 

The second change involved inclusion of a variable which 
would allow independent modelling of the two projects. This 
variable, start date (STRTDT), is aptly named in that it 
represents the time at which each project begins 
development. It can be changed to simulate different 
projects starting at different times relative to each other. 
"What if" analysis can be performed by making changes to 
this variable. This analysis can help the manager to 
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determine optimum degrees of overlap necessary to attain 
certain goals, such as minimizing costs or project duration. 

The third change, the most major one, was made to the 
human resource management subsystem. This change centered 
on addition of a centralized staff-coupling sector to be 
used in simulating the transfer of people between projects. 

A diagram of this concept is shown in Figure 6. 

The change required identification and introduction of 
many variables to accurately model the numerous factors 
involved in a manager's decision to change his workforce 
through intraorganization transfers. The high level design 
of the model is shown in Figure 7. Note that this design 
illustrates only those factors involved in transferring 
workforce from project two to project one. Transfers 
effected in the other direction require equivalent 
variables. A key to the translation of the variable names 
can be found in Figure 8; this key is also applicable to the 
variables identified in Figures 9 and 10. 

C. DESCRIPTION OF MULTIPROJECT ENVIRONMENT 

As stated earlier, the major modification to the 
existing model was addition of the changes necessary to 
simulate transfers between projects. The remainder of this 
chapter will be devoted to a description of the environment 
in which the decision to use transferred workers is made and 
how these transfers are effected. To enhance clarity in 
this discussion, only the situation in which project one has 
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Figure 7 


Design of the Multiproje^v: Staff-Coupling 
Sector 
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VAP IABLE f.EY 


ASIMF:T-=AGSIMILATION FATE OF MEW EMPLOYEES <FEDPLE/DAY> 

ASMTRP--ASSII1ILATICM DELAY OF TPAMSFEPPED PEOPLE (DAYS) 
i;EILHP = CEILING on HIPIMi’:, fop PFOJECT 1 (PEOPLE) 

HIPEF:r=HIPING PATE (FEOPLE/DAY) 

MNHPXW=MOST NEW HIPEES PEP EXPEPIEMCED STAFF (MEN/MEN) 

MXET1F=MAXIMUM WOPfFQPCE THAT CAN BE FOPCED TO TPANSFEF FROM PPOJECTD 
TO PROJECT 1 (PEOPLE) 

PFOJECT FRIQPITY=DETEPMINhTION OF WHETHER ONE PROJECT HAS PRIORITY OVER 
AMOTHEP 

DlllTPT=E>:PERIENr:ED PEOPLE CUIT PATE (PEOPLE/DAY) 

RLSCTl=WOP)FORCE TO BE RELEASED AFTER PROJECT C'S COMPLETION THAT PROJECT 
1 CAN RELY ON AND AFFORD TO WAIT POP (PEOPLE 
TOTWF= TOTAL WOPt FORCE LEVEL (PEOPLE) 

TRANSFER DELAY-DELAY PEOUIPED UNTIL TRANSFER IS AFFECTED (DAYS) 
TRMFUF^TRAnSFEPEED PEOPLE FROM PROJECT 1' TO PFOJECT 1 (PEDFLE) 
TPUFAR=TRAN3FEPRED WORKFORCE ASSIMILATION RATE INTO PROJECT I'S 
WORKFORCE (PEOPLE/DAY > 

WCWr= WILLINGNESS TO CHANGE THE WOFKFDPCE 

WFCTU=MAX IMUM WORKFORCE WE CAN FORCE TRANSFER FROM PROJECT 0 TO PROJECT 1 
AS DETERMINED BY MANAGEMENT POLICY ipEOPLE' 
wr0T10=W0PK,F0PCE WE CAN TRANSFER: FROM PROJECT 0 TO PROJECT 1 WHEN WE 

TA)E INTO CUNSIDEPATION WILLINGNESS TO PERLENISH/DELAY PRDJECT2 
WFjT lF=Wni:| FOPCE THAT WILL BE FORCIBLY TPANSFEPFED FROM PROJECT 2 TO 
PROJECT I 'PEOPLE' 

wf;:tit=total uf:pi fct-ce that will be tpamsferped from project 2 to 

P ROJEC T ; 'f-EOPLE' 

WEE riU-M'10PI FORCE TPANSFEPPEP FROM PROJECT 2 TO PROJECT 1 WILLINGLY (PECPLE 
l-;FAP'VH=WOPKFaPCE AT='P0VP:C TO HIRE (PEOPLE:’ 

WFARG- wnpi FORi E Al-’PANGED FOP. IT EPUALS UOPI FORCE + WORKFORCE TO BE 
IPAn;';rEP;--ED to FROjeCT l minus W0PKF0P:':E to be TPANSFEPPED OUT 
WFEyES’--WCR! force EXCESS. IT EPUALS WOPKFOFCE WILLING TO TPANEFEP 10 OTHE=' 
PROJECT (PEOPLE' 

UF£yp= experienced WORKFORCE (PEOPLE) 

UFGr.P;= WCP.KFDP'CE THAT NEEDS TO BE TPANSFEPPED FROM OTHER PROJECT (PEOPLE’ 
WFINDC=INDICATED WQPKFOPCE (PEOPLE) 

WFNDHP=WOFKraFCE NEEDED IF PEOPLE WILL BE HIFlED (PEOPLE) 

WFNDrP-WDPKFOPCE LEVEL NEEDED ASSUMING TRANSFERS (PEOPLE) 

WFN1-;W1=MEW WOPFOPCE (PEOPLE' 

WFOUT= WORtFORCE DEFINITELY NEEDED TO BE HIRED FROM OUTSIDE (PEOPLE) 

WFSHP= WOPKF(JRCE SOUGHT TO HIRE (PEOPLE) 

WM2T!F=W0RfFORCE NEEDED TO BE TPANSFEPPED BY FORCE FROM PROJECT 2 TO 
PROJECT 1 'PEOPLE’ 


Figure 8. Variable Key 
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Figure 10. Decomposition of WF2T1F 












priority and therefore receives transfers from project two 
will be described. 

First, the manager will determine the total number of 
workers needed (WFINDC) by ascertaining the scope of the 
project (man-days required to complete the project as it is 
estimated). He'll then compare this nvimber to the total 
workforce (TOTWF) on hand to determine the gap in the 
workforce (WFGAP). Since transferred workers tend to be 
more productive and require less assimilation time than 
their newly hired counterparts, most managers would prefer 
to meet the gap between what is needed and what is on hand 
through transfer. This determination of the need for 
transfers is a continuing process throughout the life of the 
project as the manager continually updates his estimates of 
project size and how much of the project is completed. 
Returning to Figure 7, one can see that it is through this 
transferring process that the two projects interact. Once 
the manager has determined the amount of workforce that he 
needs to have transferred to his project, there are two ways 
in which these transfers can be affected. 

First, these transferees may be people who are 
transferred willingly (WF2T1W), meaning management in 
project two acknowledges that they have more than enough 
people to get the job done. These "willing" transfers are, 
in fact, recognized as excess workforce (WFEXES) as shown in 
Figure 7. The workforce which is in excess will be 
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willingly transferred but this may not meet the needs of 
project one. The manager then realizes the number of 
individuals he needs to transfer by force (WN2T1F). This 
"forced" transferring will occur when the overall 
organizational goals can best be met through these 
transfers. 

Figure 10 presents the factors involved in determining 
what amount of the workforce will be transferred by force 
(WF2T1F). Two factors influence this determination—these 
factors are management policy and willingness to replenish 
or delay the other project. 

The first item (WF2T11) which influences forced 
transfers is management policy. This policy is, in turn, 
determined with regard to two considerations. One 
consideration is the willingness of project one to force 
transfers from project two. In the early phases of project 
development, project one will be more apt to hire from the 
outside and not disrupt the other project through forced 
transfer. This is due to reluctance to force transfers from 
the other project when it is building its "core" team (i.e., 
in the early stages of the project). The second 
consideration influencing management policy is attention 
given to the cumulative number of "recent" transfers as the 
more recently transfers have occurred in noticeable numbers 
the less apt the losing manager is to give up yet more 
people. 
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The other item (WF2T12) influencing forced transfers is 
regard for the willingness to replenish or delay the other 
project. The ability to replenish project two affects the 
number of forced transfers which take place. If the 
organization has a workforce ceiling and it is close to that 
ceiling, there will be more reluctance to replenish project 
two which will in turn lead to fewer forced transfers. The 
amount of delay which can be afforded also affects the 
number of transfers which take place. This delay is a 
function of the maximum tolerable completion date of the 
project—the "drop dead" time for completion. The minimum 
tolerable workforce with which project two can continue 
development is based on this delay. Forced transfers will 
not drive the workforce below chis number. 

The amount of workforce which will be transferred 
willingly (WF2T1W) combined with the number that can be 
transferred by force (WF2T1F) constitute the total workforce 
that will be transferred from project two to project one 
(WF2T1T). This relationship is shown in Figure 10. The 
number of individuals who make up the to-be-transferred 
force combined with the original workforce are then 
considered to be "arranged for" (WFARG) as shown in Figure 
9. Prior to the transfer being achieved, however, a 
transfer delay is incurred as preparation is made for the 
trans-fer both by project two and by the individual. Once 
the transfer is complete a period of assimilation ensues. 
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Though individuals transferred (TRNFWF) require some 
assimilation time (TRWFAR), their rate of assimilation into 
the gaining project is less than that for newly hired 
workers. This is attributable to their understanding of the 
organizational environment and their experience with the 
organization's policies and standards. Additionally, if the 
two projects are components of a larger project, the 
transferred workforce is at least somewhat familiar with 
that overall project—a familiarity which contributes to 
their faster assimilation into the workforce. As members of 
the transferred workforce are assimilated into the new 
project, they become part of the experienced workforce 
(WFEXP). 

Note that if two projects are running in parallel, 
transfers will occur only in the direction of the project 
which has higher priority (PROJECT PRIORITY) until that 
project completes. This priority status may be exogenously 
determined by organizational management as, for instance, a 
result of contract requirements. In the situation being 
described in this chapter, project one has been exogenously 
determined to have priority. Also possible is determination 
of a project's priority based on its proximity to completion 
relative to the other project. It would be foolish to 
transfer people out of a project which, due to either of the 
reasons mentioned above, had been designated as having high 
priority. 
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Having datermined the workforce arranged for, the 
manager must once again appraise his workforce situation and 
determine if he still needs to hire. He will do this by 
comparing the workforce he needs (WFINDC) to the workforce 
to which he has access (WFARG). The difference between 
these two is the gap which the manager must attempt to close 
by hiring (WFNDHR). Figure 9 shows the relationships 
between the variables which influence the acquisition of the 
entire workforce, both through transfer and through hiring. 
Though the manager may, as far as the numbers are concerned, 
need to hire a certain number of workers, other 
considerations come into play. The willingness of 
management to hire new workers (WCWF) will affect the number 
actually sought tc be hired (WFSHR). Reluctance to hire new 
workers (WFNEWl) may be due to the nearness of completion of 
the project—a manager will be less willing to hire a new 
team member the closer the project gets to completion as 
there may not be time to assimilate that member. Another 
consideration managers take into account is the ratio 
between new and experienced workers (MNHPXW). The 
productivity of experienced workers (WFEXP) will decline as 
they take the time and effort to train and socially 
assimilate their new workers. Aware of this phenomenon, 
managers will limit this ratio and will hire only in numbers 
compatible with their productivity needs. 
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Having calculated the number of workers sought to hire, 
the manager will once again look at the other project for a 
possible source of employees. He makes an informed decision 
regarding the number of individuals to be released upon the 
other project’s completion on which he can rely and for 
which he can afford to wait (RLS2T1). Since these 
individuals will be released upon completion of the project, 
the management policy (WF2T11) and willingness to replenish 
or delay (WF2T12) factors which affected transfer 
considerations will not come into play here. 

This number (RLS2T1) subtracted from the workforce 
sought to hire (WFSHR) gives the manager a final figure of 
the workforce needed to be acquired by hiring (WFOUT). 

Before these people are actually hired, however, the manager 
needs to ensure he is following organizational policy with 
regard to any ceiling on the workforce (CEILHR). Regardless 
of the number of individuals needed, the organizational 
ceiling and how that ceiling will be allocated amongst 
projects will be the final determinants of how many can be 
hired (WFAPVH). If the manager finds he is unable to get 
the people he needs, he may need to work the people he has 
harder or extend the schedule, or both. 

Returning to Figure 7, one can see that the workforce 
which has been approved to hire (WFAPVH) will increase the 
number of employees in the new workforce (WFNEWl) as they 
are hired (HIRERT). This number in turn increases the total 
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workforce (TOTWF) of that project. Once again, and 
throughout the life of the project, the manager will compare 
this figure to what he needs (WFINDC) and the cycle of 
filling the workforce gap will begin anew. It is this sort 
of cause-and-effect chain which makes the system dynamics 
approach so appropriate for the software project management 
world, especially that of multiproject organizations. 

The changes described above were incorporated into the 
existing System Dynamics model of software project 
management. Addition of the staff-coupling sector, the 
start date variable and arrays enabled modelling of a 
multiproject environment. Simulations were run with this 
new model in an attempt to replicate changes managers might 
make or contemplate in their management policies. The 
results of these simulations are presented in Chapter IV. 
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IV. EXPERIMENT RESULTS 


A. EXPERIMENTAL ENVIRONMENT 

The System Dynamics model of software project management 
was written in Dynamo, a computer simulation language which 
is described in Chapter II. The variables necessary to 
model a multiproject environment, identified in Chapter III, 
were incorporated into this Dynamo program. This program, 
run on a personal computer, provided the vehicle for the 
conduct of the experiments presented in this chapter. 

B. DESCRIPTION OF EXPERIMENTS 

After implementation of the changes made to the System 
Dynamics model of software project management, several 
experiments were conducted by running simulations. These 
experiments were conducted using the characteristics of an 
actual software project. This project, NASA's DE-A project, 
was conducted at Goddard Space Flight Center. The 
requirements for the project were to design, implement, and 
test a software system for processing telemetry data and 
providing attitude determination and control for the DE-A 
satellite. The project's size was 24,000 delivered source 
instructions. This size was initially underestimated by 35 
percent. The initial estimates of cost and schedule were 
1100 man-days and 320 days, respectively. The actual 
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results were a cost of 2200 man-days and a schedule of 380 
days. [Ref. 4:p. 1432] 

In the multiproject environment present in the extended 
model, these statistics were given to both projects. In 
most of the simulations the nominal ceiling on the total 
workforce (NCLTWF) was set to a default value of 30 
(exceptions are noted in the text). This condition enabled 
simulations to be run which showed the effect of manpower 
constraints. Results of a single project restricted in this 
manner are a cost of 1909.5 days and a schedule of 398 days. 
In this case of a single project, the nominal ceiling on the 
total workforce is 15 (one-half that for the two-project 
simulations). This constraint was not in effect in the 
actual DE-A project. Its addition does not affect the fact 
that the experiments were run with two identical projects 
both of which were in distress as they were initially 
underestimated. The results of the experiments will be 
presented in this chapter. Prior to this, however, an 
explanation of how the experiments were structured is 
necessary. 

Three sets of experiments were conducted. All three 
provide a glimpse at the capability for sensitivity analysis 
that this model provides the software project manager. The 
first of these involved running simulations to determine the 
optimal degree of overlap to minimize cost in seven 
different situations. The second set of experiments 
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consisted of simulations run based on an optima] degree of 
overlap when the project starting first had priority. In 
this case results from 13 simulations, each with a different 
independent variable, are presented. The third set of 
experiments consisted of simulations run based on an optimal 
degree of overlap when the project starting last had 
priority. Again, results from 13 simulations, each with a 
different independent variable, are presented. A more 
detailed description of each experiment precedes the 
presentation of the results peculiar to that experiment. 

C. EXPERIMENT SET ONE 

In the first set of experiments, simulations were run to 
determine the optimal degree of overlap between two projects 
necessary to minimize costs of the combined projects. In 
the first five cases, the priority was set dynamically 
(PRTYSW = 0)—that is, the project whose indicated 
completion date is farthest from its scheduled completion 
date would be the project which would receive transfers from 
the other as it is perceived to be in greater distress. As 
time progresses the project having priority will change as 
one project "gains" on the other due to the advantage of 
receiving transfers. 

1. Baseline 

Figure 11 shows the results of tests run to 
determine the optimum overlap required to minimize costs 
when dynamic priority is used. In this simulation, as in 
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all others in this experiment set (with the exception of the 
two simulations in which workforce ceiling was changed), the 
nominal ceiling on the workforce has the value of 30. Since 
Figure 11 is identical in format to the others in this 
section, a brief explanation of it is appropriate. 



SCHajULE 0VB?LAP CQAYS) 

□ INDEP o PBOJ1 A PB0J2 X TOTAL 


Figure 11. Overlap Results—Baseline 


There are four lines of results shown on this 
figure. The first, "INDEP,” indicates the combined cost of 
two projects run in parallel with no interaction; they are, 
in other words, independent of each other. No transfers 
occur between projects. This line is given as a point of 
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comparison between independent projects and projects 
developed in a multiproject environment in which human 
resources are shared. 

The second line, "PROJl,” indicates the cost for 
project one at each point of overlap. Note that for the 
five simulations run with dynamic priority (this and the 
next four), project one was always the project to start 
last. For instance, the number 20 on the X-axis indicates 
that project one started at time 20 and project two started 
at time zero. Only when the schedule overlap is zero do the 
projects start together. 

The third line, ''PR0J2,'' indicates the cost of 
project two at each degree of overlap. Recall that project 
two is always the project to start first. 

The last line, "TOTAL,” indicates the combined cost 
of both projects for each degree of overlap. This line 
provides the major point of interest as a manager trying to 
minimize overall costs would focus on this information. It 
is important to recognize that determination of which 
project starts first (in this case, project two) does not 
skew the results when the priority is dynamically set, as it 
is in five of these experiments. If project one had been 
chosen to start first, its costs would mirror those of 
project two in the current results and vice-versa. The 
total costs would remain unchanged. 
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The final area of attention with regard to Figure 11 
is the choice of 400 as the stopping point for the 
simulations. The project starting first will complete at 
time 398, the same time as if it were running in a single 
project environment. This is because it cannot receive 
transfers from a project which hasn't started yet. It would 
appear, then, that the simulations run with one project 
starting at time 400 would be in fact nothing more than the 
simulation of two independent projects as the projects seem 
to have no chance to overlap. In reality, however, even 
though one project completes at time 398, there is still 
workforce available to be transferred to the other project 
as it begins at time 400. This is due to the fact that when 
a project "ends" there are still things to be taken care of 
to "wrap" that project up. Individuals still on hand during 
this time are available for transfer to the other project. 
The results of this experiment show that the optimal degree 
of overlap occurs when the projects start at the same time. 
This is shown in the summary results in the appendix. 

2. Transfer Productivity 

In the second simulation of this experiment set, the 
variables changed were the variables which affect the 
nominal productivity of experienced people (NPPRWT) and 
transfer delay (TRNSDY). By increasing NPPRWT (from zero to 
.5) and decreasing TRNSDY (from ten to five), the scene set 
is one in which transferred people are more productive. As 
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stated earlier, the priority is set dynamically in this 
simulation. The results of the tests run to determine the 
optimum degree of overlap to minimize cost are shown in 
Figure 12. The summary of the results is contained in the 
appendix. They show that the optimal degree of overlap 
occurs when the projects start at the same time. 



3. Workforce Ceiling 

In this set of simulations, the ceiling on the 
organizational workforce was decreased from the default 
value of 30 to 20. The priority is, once again, determined 
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dynamically. The results of the efforts to determine the 
optimum degree of overlap to minimize costs under these 
conditions are shown in Figure 13. The summary results are 
presented in the appendix. They show that the optimal 
overlap occurs under these conditions when one project 
starts 400 days after the other. 



Figure 13. Overlap Results—Workforce Ceiling 


4. Workforce Ceiling and Allocation 

In this scenario, the conditions were the same as in 
the third, above, with the addition of one other change. 

The allocation of the workforce ceiling was set such that 
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the project with priority could employ up to the ceiling on 
workforce for the entire organization, leaving the other 
project with no pool from which to acquire additional 
workforce (POLCYl = 0). Normally, the ceiling is allocated 
on a 50:50 basis, with each project allowed to employ up to 
one-half the workforce ceiling (POLCYl = 1). Results of 
cost minimization simulation runs are shown in Figure 14; 
summary results are shown in the appendix. Starting one 
project 160 days after the other provides the optimal degree 
of overlap. 



Figure 14. Overlap Results—Workforce Ceiling and 
Allocation 
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5. Hiring and Transferring Aggressiveness 


In this set of simulations, the variables affecting 
the aggressiveness in hiring (TMPRMR) and receiving 
transfers (TAGRSV) were changed to model a situation in 
which the manager is more aggressive in these areas. TMPRMR 
was decreased from 50 to 25 and TAGRSV was decreased from 
one to .5. Note that a decrease in these variables caused 
an increase in aggressiveness. This is the last set of 
simulations in which the priority is dynamically set. 

Figure 15 shows the results of the simulation runs for 
optimizing overlap in regard to minimizing cost. The 
appendix provides a summary of these results. In this 
setting the optimal degree of overlap occurs when one 
project starts 300 days after the other. 

6. Project Starting First Has Priority 

In this set of simulations, as in the next, the 
project priority is set statically (PRTYSW = 1). That 
project which will have priority is determined at the 
beginning of the simulation by the manager and remains 
unchanged throughout. In this and the next set of 
simulations, project one has priority (TRPYll = 1). In this 
set, project one is also the project which starts first; 
therefore, when the X-axis is labelled, for instance, 100, 
this means that project one started at time zero and project 
two started at time 100. Figure 16 shows the results of 
this experiment in which the optimal degree of overlap is 
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SCHEDULE OVB?LAP CDAYSJ 

□ INDEP * PRCU1 A PR0J2 X TCtTAL 


Figure 15. Overlap Results—Hiring and Transferring 
Aggressiveness 


reached when project one starts 120 days before project two. 
A summary of these results is provided in the appendix. 

These results will be used in determining a starting point 
for the second set of experiments. 

7. Project Starting Last Has Priority 

In this set, project one also has priority but in 
contrast to the sixth set of simulations, above, it is the 
project which starts last; therefore, when the X-axis is 
labelled, for instance, 100, this means that project one 
started at time 100 and project two started at time zero. 
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SCHEDULE 0VB5LAP CDAYS5 

□ INDEP O PR0J1 & PflCU2 X total 

Figure 16. Overlap Results—Project Starting First Has 
Priority 

Figure 17 shows the results of this experiment in which the 
optimal degree of overlap occurs when project one starts 100 
days after project two. The appendix provides a summary of 
the results. These results will be used in determining a 
starting point for the third set of experiments. 

8. Summary 

Figure 18 provides a graph showing the different 
optimum degrees of overlap with which to minimize cost for 
each simulation in experiment set one. Tht results attained 
in this experiment set all provide points for further 
analysis. To provide the reader with an understanding of 
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SCHHIULE OVERLAP CDAYS5 

□ INDEP o PKUI A PRCU2 X TOTAL 

Figure 17. Overlap Results—Project Starting Last Has 
Priority 

the factors that may lead to these results, a short analysis 
of two of the more extreme results will be presented here. 

The first simulation to be discussed is simulation 
three in which the nominal ceiling on the total workforce 
was reduced from 30 to 20. In this simulation, costs were 
minimized when one project started 400 days after the other. 
The effects of hiring and transferring people may be the 
reason for this. For instance, when two projects run at 
approximately the same time as is the case when, say, 
project one starts 60 days after project two, transferring 
of personnel does not occur until relatively late in the 
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Figure 18. Graphic Results of Experiment Set One 

projects as neither can afford to give them up earlier. 

This coupled with the decreased ability to hire as a result 
of the decrease in the workforce ceiling leads to less 
overall productivity. The change in productivity happens 
since transferred workers are assimilated later in the 
projects and are not able to "pull their load” for very 
long. Additionally, new workers are fewer in number than 
when the workforce ceiling is higher. When productivity is 
decreased, costs increase. In the case in which the 
projects start very far apart, as in this simulation in 
which one project starts 400 days after the other, the 












project starting later is able to get transfers almost 
immediately since the other project has completed. The 
reduced number of people it can hire does not affect it in 
an adverse way because the transferred people contribute 
their share to the accomplishment of the workload throughout 
the project's lifecycle. 

The other simulation of interest is the fifth 
simulation in which the aggressiveness of the manager in 
hiring and transferring is increased. The minimal cost is 
achieved when one project starts 300 days after the other. 
This is also caused by hiring and transferring. When the 
projects are running at approximately the same time, 
transfers occur throughout the life of both projects. When 
one project ends, the other aggressively seeks transfers 
even though it may be near completion. This decreases 
productivity and increases cost. When the projects start 
further apart, though, transfers occur earlier in the life 
of the second project allowing earlier realization of the 
benefits in productivity of the transferred workers and thus 
reducing cost. 

This brief analysis of these two simulations 
provides insight into some of the factors affecting software 
project management in a multiproject environment. A more 
detailed analysis of these as well as the other simulations 
in this experiment set should increase the understanding of 


47 









the complex and interdependent variables affecting cost 
minimization under different situations. 

D. EXPERIMENT SET TWO 

The second set of experiments involved simulations run 
when the project starting first had priority. As 
illustrated in Figure 16, costs were minimized when the 
project having priority, project one, began 120 days before 
the project without priority. In each of the follow-on 
simulations run under this scenario, the start date of the 
second project was set to 120. Other parameters of note 
which remained unchanged throughout this scenario, unless 
otherwise indicated, include the project priority as already 
discussed, and the workforce ceiling allocation policy. The 
default value for this parameter was such that the workforce 
ceiling was allocated on a 50:50 basis between projects. 
Also, the nominal ceiling on the total workforce was set to 
30 thus allowing no more than 30 employees in the entire 
organization. Unlike the previous set of experiments these 
were not conducted to determine the optimum overlap to 
minimize cost. Rather, as stated above, the overlap was set 
and other variables were manipulated in order to provide 
points of comparison between different conditions in an 
optimum overlap situation. These results are graphically 
presented in Figure 19. Table 1 provides a summary of the 
simulations run in this scenario. The names of each 
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Figure 19. Graphic Results of Experiment Set Two 

independent variable are explained in the section pertaining 
to that simulation. The reader will note that several of 
the variables manipulated in the first set of experiments 
were also changed in this and the third set of experiments. 

1. Baseline 

The first simulation presented is the "baseline" 
simulation in which project one has higher priority, project 
one started 120 days before project two, the workforce 
ceiling allocation policy is 50:50, and the ceiling on the 
total workforce is 30. This simulation provides a basis for 
comparisons with others within this experiment sev. 
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TABLE 1 

RESULTS FROM EXPERIMENT SET TWO SIMULATIONS 


■ 

Independent 

Cost 

Schedule 

Transfers 

Transfers 

■ 

Variable 

(Man-days) 

(Days) 

2 to 1 

1 to 2 

1 

BASELINE 

3690.93 

519.50 

-8.84 

8.84 

2 

TRPYll 

3804.75 

447.00 

2.34 

-2.34 

3 

PRTYSW 

3929.72 

468.00 

-16.21 

16.21 

4 

POLCYl 

4343.44 

514.50 

-16.89 

16.89 

5 

TAGRSV 

3690.93 

519.50 

.84 

8.84 

6 

T2T1F2 

T1T2F2 

3690.93 

519.50 

-8.84 

8.84 

1 

TB2T11 

TB1T21 

3690.26 

519.50 

-8.84 

8.84 

8 

TC2T11 

TC1T21 

3659.45 

540.50 

-8.24 

8.24 

9 

FORGETa 

3670.27 

541.00 

-8.33 

8.33 

10 

FORGETb 

3742.06 

501.50 

-9.34 

9.34 

11 

TMP1R2 

TMPIRI 

3690.03 

519.50 

-8.84 

8.84 

12 

TWRL2Tla 

TWRLlT2a 

3770.12 

618.50 

-12.85 

12.85 

13 

TWRL2Tlb 

TWRLlT2b 

3733.06 

498.00 

6.34 

-6.34 


Figure 20 provides a statistical report on the 
results of this simulation. The statistical reports for all 
simulations to be presented in this and the next section 
will be identical in format to that presented in this 
figure. These reports are, for the most part, self- 
explanatory. Note that statistics, including total effort, 
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PROJECT STATISTICS: 

COMPLETION TIME ONE 

374.50 

PORTION OF 
TOTAL EFFORT 

DAYS 

TOTAL EFFORT ONE 1 

,863.02 

MAN-DAYS 


QA EFFORT ONE 

457.20 

MAN-DAYS 

.25 

DEVELOP EFFORT ONE 

863.15 

MAN-DAYS 

.46 

REWORK EFFORT ONE 

261.58 

MAN-DAYS 

.14 

TESTING EFFORT ONE 

232.22 

MAN-DAYS 

.12 

TRAINING EFFORT ONE 

48.86 

MAN-DAYS 

.03 

OVERALL-PRODUCTIVITY ONE 

13.10 

TASKS/MAN-DAY 


COMPLETION TIME TWO 

519.50 

DAYS 


TOTAL EFFORT TWO 1 

,827.91 

MAN-DAYS 


QA EFFORT TWO 

411.77 

MAN-DAYS 

.23 

DEVELOP EFFORT TWO 

881.43 

MAN-DAYS 

.48 

REWORK EFFORT TWO 

265.20 

MAN-DAYS 

. 15 

TESTING EFFORT TWO 

245.93 

MAN-DAYS 

. 13 

TRAINING EFFORT TWO 

23.58 

MAN-DAYS 

.01 

OVERALL-PRODUCTIVITY TWO 

13.35 

TASKS/MAN-DAY 


NET TRANSFERS 2 TO 1 

- 8.84 

MEN 


NET TRANSFERS 1 TO 2 

8.84 

MEN 


TOTAL EFFORT - BOTH 3 

,690.93 

MAN-DAYS 



Figure 20. Simulation 1—Statistical Results 


are presented for project one first followed by those for 
project two. Finally, the net transfers between projects 
(transfers from a project subtracted from transfers into 
that project) are shown followed by the total effort in man- 
days of the combined projects. It is the total effort, 
whether for each project or combined, which represents the 
"cost” inherent to each situation. 
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Graphical reports identical in format to Figures 21 
and 22 will also be presented for each simulation throughout 
this and the following section. Figure 21 illustrates the 
relationship between the scheduled completion dates 
(SCHCDT ), measured in days, of the two projects as well as 
the relationship between the total workforce (TOTWF), 
measured in men, of both projects. Also of interest is the 
relative relationship between the values of these variables 
themselves. For instance, project two has neither a 
scheduled completion date or any workforce assigned it until 
it begins at time 100. Once it begins, however, the 
scheduled completion date remains relatively stable then 
drops and finally rises again. The total workforce 
consistently rises throughout the life of the project and 
then drops rapidly once it is completed. Comparisons of 
absolute values of these variables is inadvisable because 
they are plotted on different scales, as can be seen on the 
left hand side of the graphs. Identification of which scale 
belongs to which variable can be made by comparing the 
minimum and maximum value of the scale to the figures 
immediately following the variables at the top of the 
graph. 

Figure 22 presents the relationship between the 
total workforce (TOTWF) and the transferred workforce 
(TRNFWF), both of which are measured in number of men. 

Recall that as transferred individuals are assimilated into 
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Figure 21. Simulation 1—Graph 1 



53 
















the workforce of the gaining project, they become 
experienced workforce and are no longer reflected in the 
TRNFWF value. Caution is once again advised in any attempt 
to compare absolute values for these variables for the same 
reason mentioned in the paragraph above. More interesting, 
in any case, is their movement on the graph relative to each 
other. Since in this simulation, as in most simulations, 
project one has priority, there will be no transfers to 
project two until project one completes. Note that in both 
graphs, as in all graphs presented as simulation results, 
time is measured in days. 

2. TRPYll 

In this simulation, the priority of the projects 
(TRPYll) was switched (from TRPYll = 1 to TRYPll =0). In 
the default, project one has priority. In this simulation, 
project two was given priority and as such all transfers 
would occur in the direction of project one to project two 
until project two completes. Results from this run are 
shown in Figures 23, 24, and 25. 

3. PRTYSW 

The third simulation in this set involved changing 
the way in which priority is determined. Instead of a 
single project always having priority (PRTYSW = 1), as 
determined exogenously by management, the priority in this 
simulation is determined dynamically (PRTYSW = 0). This is 
comparable to the conditions under which the first five 
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Figure 23. Simulation 2—Statistical Results 
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simulations in experiment set one were run. Results from 
this simulation are shown in Figures 26, 27, and 28. 

4. POLCYl 

In this simulation, the variable changed was that 
which affects the management policy regarding how the 
workforce ceiling is allocated (POLCYl). In lieu of having 
a 50:50 allocation (POLCYl =1), in which each project gets 
50 percent of the ceiling, the policy was changed (POLCYl = 
0). This simulation represents the effects of an allocation 
policy in which the project which has priority is allowed to 
hire in whatever numbers it needs up to the ceiling; the 
second project can hire only the workforce representing the 
difference between what the first project has hired and the 
organizational ceiling. Of note is the fact that in either 
case the default ceiling of 30 is sufficient for both 
projects to complete on time without undue pressure 
resulting from this ceiling if the workforce is acquired 
early enough to allow for assimilation. Results from this 
simulation are presented in Figures 29, 30, and 31. 

5. TAGRSV 

In the fifth simulation, the variable affecting the 
aggressiveness of the manager and his willingness to change 
the workforce assuming transfers will occur (TAGRSV) is 
changed. It is decreased from one to .5. The consequence 
of this change is to simulate a manager who is more willing 
to transfer people from the other project (project two). 
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Figure 26. Simulation 3—Statistical Results 
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Figure 29. Simulation 4—Statistical Results 
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Figure 30, Simulation 4—Graph 1 
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Results from this simulation are shown in Figures 32 , 33 , 
and 34. 

6. T2T1F2 and T1T2F2 

Similar to the fifth simulation, the effect of the 
change in this run of the model was to simulate a manager 
who is more willing to transfer workforce by force from the 
other project to meet his manpower needs. These variables 
(T2T1F2 and T1T2F2) model willingness to force transfers as 
a function of the percent reported completed of the second 
project. They are originally set to values which indicate 
an unwillingness on the manager's part to force transfers 
from a project just beginning. This is because the manager 
realizes the importance of not disrupting a project in its 
early stages, when it is building its core team. Thus even 
though project one has priority, its manager would not be 
willing to force transfers from project two because he knew 
it was in its "building up" stage. In this case both the 
variable affecting project one and its equivalent (T2T1F2 
and T2T1F2) were increased in value such that this period of 
non-disruption is denied. The default values of these 
variables are 0/.2/.5/.9/1/1 while the new values as used in 
this simulation are l/l/l/l/l/l. Values such as these 
represent table functions in the Dynamo language. In table 
functions each number is associated with the occurrence of 
an event. For instance, in this example, a manager would 
have "0" willingness to force transfers when project two was 
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Figure 32. Simulation 5—Statistical Results 
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Figure 33. Simulation 5—Graph 1 
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Figure 34. Simulation 5—Graph 2 
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reporting zero percent completion. A more detailed 
discussion of the table function and its application, while 
beyond the scope of this work, can be found in Alexander 
Pugh's book, Dvnamo User's Manual . However, in several 
cases these types of values are included in the description 
of the simulation to enable duplication of these simulations 
in follow-up research. Results from this simulation are 
given in Figures 35, 36, and 37. 

7. TB2T11 and TB1T21 

In this simulation another variable and its 
equivalent (TB2T11 and TB1T21) were changed. These 
variables are used in conjunction with those described in 
simulation eight to ascertain the overall fraction of his 
workforce the manager can be forced to transfer. These 
variables provide input to this fraction as a function of 
the percent reported completed of the second project. In 
the default situation project one will not force transfers 
from project two at all until it is at least ten percent 
complete. The contribution of these two variables is zero 
until this time causing a zero fraction of the workforce to 
be forcibly transferred. The change effected in this 
simulation was such that these variables no longer had any 
effect on the overall fraction of the workforce to be trans¬ 
ferred—a simulation which could be used to ascertain if the 
concept which these variables model is an actual concern of 
managers. If the change does not produce significantly 
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Figure 35. Simulation 6—Statistical Results 
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Figure 36. Simulation 6—Graph 1 
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Figure 37. Simulation 6—Graph 2 























different results from the baseline case, then this variable 
has little effect on the manager's decision. The default 
values of these variables are 0/.2/.5/.9/1/1 and the values 
on which this simulation were based are l/l/l/l/l/l. 

Figures 38, 39, and 40 illustrate the results. 

8. TC2T11 and TC1T21 

In this simulation the variable affecting the 
fraction of his workforce a manager can be forced to 
transfer as a function of the cumulative recentness of 
transfers and its equivalent in the other project are 
increased (TC2T11 and TC1T21). These variables are used in 
conjunction with those described in simulation seven to 
ascertain the overall fraction of his workforce the manager 
can be forced to transfer. The default values of these 
variables (11 values ranging from .5 to zero) are such that 
if a manager has recently transferred out a large portion of 
his workforce he will not be forced to transfer any more 
individuals at the present time. These values were 
increased (all 11 values are now equal to the value one). 

The change effected in this simulation was such that these 
variables no longer had any affect on the overall fraction 
of the workforce to be transferred—a simulation which could 
be used to ascertain if the concept which these variables 
model is an actual concern of managers. If the change does 
not produce significantly different results from the baseline 
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Figure 38. Simulation 7—Statistical Results 
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Figure 39. Simulation 7—Graph 1 
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case then this variable has little effect on the manager's 
decision. Figures 41, 42, and 43 pertain. 


9. FORGETa 

In the ninth simulation, the time it takes a manager 
to "forget" about recent transfers (FORGET) was decreased 
from the default value of 60 to 30. This variable affects 
the willingness of that manager to transfer more of his 
workforce. The lower the value of this variable, the more 
apt the manager is to allow transfers as he has already 
forgotten about relatively recent transfers. Results are 
provided in Figures 44, 45, and 46. 

10. FORGETb 

The amount of time it takes a manager to "forget" 
about recent transfers (FORGET) was increased over the 
default value from 60 to 120. More information is provided 
in the description of simulation nine. See the results in 
Figures 47, 48, and 49. 

11. TMP1R2 and TMPIRI 

In this experiment, the impact of the hiring ceiling 
on the willingness to force transfers from a project because 
its workforce could be replenished is changed as is its 
equivalent in the other project (TMP1R2 and TMPIRI). This 
change allows simulation of a situation in which the ceiling 
has less of an impact on the final decision than in the 
baseline case. Note that the result of the change is less 
of an impact although the default values of these variables 
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Figure 41. Simulation 8—Statistical Results 
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Figure 44. Simulation 6—Statistical Results 
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Figure 46. Simulation 9—Graph 2 
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Figure 47. Simulation 10—Statistical Results 
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were increased from 0/.S/.1^/.9/.915/1/1/1/1/1/1 to all 
one's. The results of the simulation are presented in 
Figures 50, 51, and 52. 

12. TWRL2Tla and TWRLlT2a 

The manager's willingness to rely on the release of 
people from a completing project and its equivalent in the 
other project are the independent variables in this 
simulation (TWRL2T1 and TWRL1T2). This willingness is a 
ratio of the time remaining (for the completing project) to 
the hiring delay; the higher the ratio, the less apt the 
manager is to wait in the baseline scenario. In this 
simulation, this willingness was increased, from 
1/.5/.25/.1/0/0, the default values, to l/l/l/l/l/l. This 
increase simulates a manager who is always willing to rely 
on release of personnel from the other project regardless of 
how much longer it has before completion. Figures 53, 54, 
and 55 provide results. 

13. TWRL2Tlb and TWRLlT2b 

Once again, the manager's willingness to rely on the 
release of people from a completing project is the 
independent variable. However, in this case, this 
willingness was decreased from the default values given in 
the description of simulation 12 to O/O/O/O/O/O. This 
decrease causes the situation in which the manager will 
never rely on people from the other project based on its 
completion. Figures 56, 57, and 58 are relevant. 
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Figure 50. Simulation 11—Statistical Results 
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Figure 51. Simulation 11—Graph 1 



Figure 52. Simulation 11—Graph 2 
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Figure 53. Simulation 12—Statistical Results 
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Figure 54. Simulation 12—Graph 1 



Figure 55. Simulation 12—Graph 2 
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Figure 56. Simulation 13—Statistical Results 
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Figure 57. Simulation 13—Graph 1 
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14. Summary 


This set of experiments supports comparisons of 
costs in simulations in which the project starting first has 
priority. In-depth analysis of each simulation is of 
interest to the manager wishing to understand in more detail 
the complexities of software project management. Following 
is a brief analysis of two of the simulations in this 
experiment set. 

Simulation three resulted in costs higher than 
average for this experiment set. In this simulation, the 
project which will have priority is determined by the model 
as a function of which project's indicated completion date 
is farthest from its scheduled completion date. That 
project in the most trouble, i.e., whose indicated 
completion date is farthest from its scheduled completion 
date, will receive transfers. This scenario causes an 
increase in the number of transfers over the baseline 
results as priority is continually reassigned back and forth 
between projects. Additional transfers cause increased 
training and assimilation time and decrease overall 
productivity. This in turn causes a greater expenditure of 
effort, resulting in the increased costs seen in this 
simulation. 

One of the most interesting results of this 
experiment set was attained when the way in which the 
workforce ceiling was allocated was changed. This change 
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was effected in simulation four. Instead of each project 
being allocated 50 percent of new hires, up to the workforce 
ceiling for the organization, the project having priority, 
project one, is allowed to hire what it wants up to the 
ceiling. If the ceiling is not reached, project two can 
then hire up to the ceiling. Project two, therefore, is 
unable to hire in the numbers it would like. This causes 
project two to rely on transfers from project one, after 
project one has completed. This increased nvimber of 
transfers relatively late in project two's development 
causes decreased productivity and increased costs. 

These brief analyses provide the reader with some 
insight into how different management decisions can affect 
the costs of developing software projects in a multiproject 
environment. As in experiment set one, a more detailed 
analysis of these results is an appropriate area for follow- 
on research. 

E. EXPERIMENT SET THREE 

The third set of experiments involved simulations run 
when the project starting last had priority. As illustrated 
in Figure 17, costs were at a low point when the project 
having priority, project one, began 100 days after the 
project without priority. The actual minimum cost appears 
to be at time 300 but running simulations with this great a 
disparity in start dates would minimize the effects of the 
overlap mechanism. In each of the follow-on simulations run 
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under this scenario, the start date of the first project was 
set to 100. In all other ways, this set of experiments is 
identical to those run in experiment set two. For ease in 
reading, the descriptions of the simulations are repeated 
here. Recall that other parameters of note which remained 
unchanged throughout this scenario, unless otherwise 
indicated, include the project priority and the workforce 
ceiling allocation policy. Table 2 provides a summary of 
the simulations run in this set of experiments. These 
results are graphically presented in Figure 59. 

1. Baseline 

The first simulation presented is the "baseline" 
simulation in which project one has higher priority, project 
one started 100 days after project two, the workforce 
ceiling allocation policy is 50:50, and the ceiling on the 
total workforce is 30. This simulation provides a basis for 
comparisons with others within this experiment set. Figures 
60, 61, and 62 pertain. 

2. TRPYll 

In this simulation, the priority of the projects 
(TRPYll) was switched (from TRPYll = 1 to TRYPll = 0). In 
the default, project one has priority. In this simulation, 
project two was given priority and as such all transfers 
would occur in the direction of project one to project two 
until project two completes. Results from this run are 
shown in Figures 63, 64, and 65. 
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TABLE 2 


RESULTS FROM EXPERIMENT SET THREE SIMULATIONS 


1 

Independent 

Variable 

Cost 

(Man-days) 

Schedule 

(Days) 

Transfers 
2 to 1 

Transfers 
1 to 2 

1 

BASELINE 

3790.05 

440.50 

-3.28 

3.28 

2 

TRPYll 


488.50 

7.61 

-7.61 

3 

PRTYSW 

3951.43 

465.00 

13.99 

-13.99 

4 

POLCYl 

3841.57 

440.50 

-4.62 

4.62 

5 

TAGRSV 

3788.37 

442.00 

-3.16 

3.16 

6 

T2T1F2 

T1T2F2 

3790.23 

440.50 

-3.28 

3.28 

1 

TB2T11 

TB1T21 

3790.05 

440.50 

-3.28 

3.28 

8 

TC2T11 

TC1T21 

3952.07 

456.50 

-3.80 

3.80 

9 

FORGETa 

3940.73 

451.50 

-3.73 

3.73 

10 

FORGETb 

3746.54 

431.00 

6.38 

-6.38 

11 

TMP1R2 

TMPIRI 

3790.10 

440.50 

-3.28 

3.28 

B 

TWRL2Tla 

TWRLlT2a 

3710.61 

446.00 

20.12 

-20.12 

13 

TWRL2Tlb 

WRLlT2b 

3782.80 

467.00 

11.12 

-11.12 
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Figure 59. Graphic Results of Experiment Set Three 

3. PRTYSW 

The third simulation in this set involved changing 
the way in which priority is determined. Instead of a 
single project always having priority (PRTYSW = 1), as 
determined exogenously by management, the priority in this 
simulation is determined dynamically (PRTYSW = 0). This is 
comparable to the conditions under which the first five 
simulations in experiment set one were run. Results from 
this simulation are shown in Figures 66, 67, and 68. 
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Figure 60. Simulation 1—Statistical Results 
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Figure 63. Simulation 2—Statistical Results 
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PROJECT STATISTICS; 


PORTION OF 
TOTAL EFFOR' 


COMPLETION TIME ONE _ 465.00 DAYS 
TOTAL EFFORT ONE 2,028.94 MAN-DAYS 

QA EFFORT ONE 517.28 MAN-DAYS .25 
DEVELOP EFFORT ONE 933.40 MAN-DAYS .46 
REWORK EFFORT ONE 268.56 MAN-DAYS .13 
TESTING EFFORT ONE 285.46 MAN-DAYS .14 
TRAINING EFFORT ONE 24.24 MAN-DAYS .01 


OVERALL-PRODUCTIVITY ONE 12.03 TASKS/MAN-DAY 


COMPLETION TIME TWO 399.00 DAYS 
TOTAL EFFORT TWO 1,922.49 MAN-DAYS 

QA EFFORT TWO 494.60 MAN-DAYS .26 
DEVELOP EFFORT TWO 882.91 MAN-DAYS .46 
REWORK EFFORT TWO 262.31 MAN-DAYS .14 
TESTING EFFORT TWO 240.34 MAN-DAYS .13 
TRAINING EFFORT TWO 42.32 MAN-DAYS .02 
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NET TRANSFERS 2 TO 1 13.99 MEN 

NET TRANSFERS 1 TO 2 - 13.99 MEN 

TOTAL EFFORT - BOTH _ 3,951.43 MAN-DAYS _ 

Figure 66. Simulation 3—Statistical Results 
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Figure 67. Simulation 3—Graph 1 
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4. 


POLCYl 


In this simulation, the variable changed was that 
which affects the management policy regarding how the work¬ 
force ceiling is allocated (POLCYl). In lieu of having a 
50:50 allocation (POLCYl =1), in which each project gets 50 
percent of the ceiling, the policy was changed (POLCYl = 0). 
This simulation represents the effects of an allocation 
policy in which the project which has priority is allowed to 
hire in whatever numbers it needs up to the ceiling; the 
second project can hire only the workforce representing the 
difference between what the first project has hired and the 
organizational ceiling. Of note is the fact that in either 
case the default ceiling of 30 is sufficient for both 
projects to complete on time without undue pressure 
resulting from this ceiling if the workforce is acquired 
early enough to allow for assimilation. Results from this 
simulation are presented in Figures 69, 70, and 71. 

5. TAGRSV 

In the fifth simulation, the variable affecting the 
aggressiveness of the manager and his willingness to change 
the workforce assuming transfers will occur (TAGRSV) is 
changed. It is decreased from one to .5. The consequence 
of this change is to simulate a manager who is more willing 
to transfer people from the other project (project two). 
Results from this simulation are shown in Figures 72, 73, 
and 74. 
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Figure 69. Simulation 4—Statistical Results 
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Figure 70. Simulation 4—Graph 1 
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Figure 72. Simulation 5—Statistical Results 
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Figure 73. Simulation 5—Graph 1 
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6. T2T1F2 and T1T2F2 


Similar to the fifth simulation, the effect of the 
change in this run of the model was to simulate a manager 
who is more willing to transfer workforce by force from the 
other project to meet his manpower needs. These variables 
(T2T1F2 and T1T2F2) model willingness to force transfers as 
a function of the percent reported completed of the second 
project. They are originally set to values which indicate 
an unwillingness on the manager's part to force transfers 
from a project just begin ting. This is because the manager 
realizes the importance of not disrupting a project in its 
early stages, when it is building on its core team. Thus 
even though project one has priority, its manager would not 
be willing to force transfers from project two because he 
knew it was in its "building up" stage. In this case both 
the variable affecting project one and its equivalent 
(T2T1F2 and T2T1F2) were increased in value such that this 
period of non-disrviption is denied. The default values of 
these variables are 0/.2/.5/.9/1/1 while the new values as 
used in this simulation are l/l/l/l/l/l. The reader is 
reminded that values such as these represent table functions 
in the Dynamo language. In table functions each number is 
associated with the occurrence of an event. For instance, 
in this example, a manager would have "0" willingness 
to force transfers when project two was reporting zero 
percent completion. A more detailed discussion of the table 
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function and its application, while beyond the scope of this 
work, can be found in Alexander Pugh's book, Dvnamo User's 
Manual . However, in several cases these types of values are 
included in the description of the simulation to enable 
duplication of these simulations in follow-up research. 
Results from this simulation are given in Figures 75, 76, 
and 77. 

7. TB2T11 and TB1T21 

In this simulation another variable and its 
equivalent (TB2T11 and TB1T21) were changed. These 
variables are used in conjunction with those described in 
simulation eight to ascertain the overall fraction of his 
workforce the manager can be forced to transfer. These 
variables provide input to this fraction as a function of 
the percent reported completed of the second project. In 
the default situation project one will not force transfers 
from project two at all until it is at least ten percent 
complete. The contribution of these two variables is zero 
until this time causing a zero fraction of the workforce to 
be forcibly transferred. The change effected in this 
simulation was such that these variables no longer had any 
affect on the overall fraction of the workforce to be 
transferred—a simulation which could be used to ascertain 
if the concept which these variables model is an actual 
concern of managers. If the change does not produce 
significantly different results from the baseline case, then 
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Figure 75. Simulation 6—Statistical Results 
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Figure 77. Simulation 6—Graph 2 


















this variable has little effect on the manager's decision. 
The default values of these variables are 0/.2/.5/.9/1/1 and 
the values on which this simulation were based are 
l/l/l/l/l/l. Figures 78, 79, and 80 illustrate the results. 

8. TC2T11 and TC1T21 

In this simulation the variable affecting the 
fraction of his workforce a manager can be forced to 
transfer as a function of the cumulative recentness of 
transfers and its equivalent in the other project are 
increased (TC2T11 and TC1T21). These variables are used in 
conjunction with those described in simulation seven to 
ascertain the overall fraction of his workforce the manager 
can be forced to transfer. The default values of these 
variables (11 values ranging from .5 to zero) are such that 
if a manager has recently transferred out a large portion of 
his workforce he will not be forced to transfer any more 
individuals at the present time. These values were 
increased (all 11 values are now equal to the value one). 

The change effected in this simulation was such that these 
variables no longer had any affect on the overall fraction 
of the workforce to be transferred—a simulation which could 
be used to ascertain if the concept which these variables 
model is an actual concern of managers. If the change does 
not produce significantly different results from the 
baseline case than this variable has little effect on the 
manager's decision. Figures 81, 82, and 83 pertain. 
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Figure 78. Simulation 7—Statistical Results 
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.27 

DEVELOP EFFORT 

TWO 

919.06 

MAN-DAYS 

.45 

REWORK EFFORT TWO 

262.08 

MAN-DAYS 

.13 

TESTING EFFORT 

TWO 

263.22 

MAN-DAYS 

.13 

TRAINING EFFORT 

TWO 

45.64 

MAN-DAYS 

.02 

OVERALL-PRODUCTIVITY 

TWO 

12.03 

TASKS/MAN-DAY 


NET TRANSFERS 2 TO 1 


- 3.80 

MEN 


NET TRANSFERS 1 TO 2 


3.80 

MEN 


TOTAL EFFORT - BOTH 

3 

,952.07 

MAN-DAYS 



Figure 81. Simulation 8—Statistical Results 
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DAYS/MEN 



Figure 82. Simulation 8—Graph 1 



Figure 83. Simulation 8—Graph 2 
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9. 


FORGETa 

In the ninth simulation, the time it takes a manager 
to "forget” about recent transfers (FORGET) was decreased 
from the default value of 60 to 30. This variable affects 
the willingness of that manager to transfer more of his 
workforce. The lower the value of this variable, the more 
apt the manager is to allow transfers as he has already 
forgotten about relatively recent transfers. Results are 
provided in Figures 84, 85, and 86. 

10. FORGETb 

The amount of time it takes a manager to "forget" 
about recent transfers (FORGET) was increased over the 
default value from 60 to 120. More information is provided 
in the description of simulation nine. See the results in 
Figures 87, 88, and 89. 

11. TMP1R2 and TMPIRI 

In this experiment, the impact of the hiring ceiling 
on the willingness to force transfers from a project because 
its workforce could be replenished is changed as is its 
eguiva-lent in the other project (TMP1R2 and TMPIRI). This 
change allows simulation of a situation in which the ceiling 
has less of an impact on the final decision than in the 
baseline case. Note that the result of the change is less 
of an impact although the default values of these variables 
were increased from 0/.5/.75/.9/.975/1/1/1/1/1/1 to all 
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PROJECT STATISTICS: 


PORTION OF 
TOTAL effort! 


COMPLETION TIME ONE* 


403.50 

DAYS 


TOTAL EFFORT ONE 

1 

,932.46 

MAN-DAYS 


QA EFFORT ONE 


431.22 

MAN-DAYS 

.22 

DEVELOP EFFORT 

ONE 

922.17 

MAN-DAYS 

.48 

REWORK EFFORT ONE 

276.22 

MAN-DAYS 

. 14 

TESTING EFFORT 

ONE 

278.50 

MAN-DAYS 

.14 

TRAINING EFFORT 

ONE 

24.34 

MAN-DAYS 

.01 

OVERALL-PRODUCTIVITY 

ONE 

12.63 

TASKS/MAN-DAY 


COMPLETION TIME TWO 


451.50 

DAYS 


TOTAL EFFORT TWO 

2 

,008.27 

MAN-DAYS 


QA EFFORT TWO 


523.42 

MAN-DAYS 

.26 

DEVELOP EFFORT ' 

TWO 

906.33 

MAN-DAYS 

.45 

REWORK EFFORT TWO 

260.13 

MAN-DAYS 

. 13 

TESTING EFFORT 

TWO 

272.78 

MAN-DAYS 

. 14 

TRAINING EFFORT 

TWO 

45.59 

MAN-DAYS 

.02 

OVERALL-PRODUCTIVITY 

TWO 

12.15 

TASKS/MAN-DAY 


NET TRANSFERS 2 TO 1 


- 3.73 

MEN 


NET TRANSFERS 1 TO 2 


3.73 

MEN 


TOTAL EFFORT - BOTH 

3 

,940.73 

MAN-DAYS 



Figure 84. Simulation 9—Statistical Results 


111 










e, 189. 298. 398. 409. 459. 

DAYS 

Figure 85. Simulation 9—Graph 1 
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PROJECT STATISTICS: 


PORTION 

OF 



TOTAL EFFORT^ 

COMPLETION TIME ONE' 

431.00 

DAYS 


TOTAL EFFORT ONE 1 

,812.26 

MAN-DAYS 


QA EFFORT ONE 

423.73 

MAN-DAYS 

.23 

DEVELOP EFFORT ONE 

869.74 

MAN-DAYS 

.48 

REWORK EFFORT ONE 

262.12 

MAN-DAYS 

.14 

TESTING EFFORT ONE 

229.19 

MAN-DAYS 

. 13 

TRAINING EFFORT ONE 

27.47 

MAN-DAYS 

.02 

OVERALL-PRODUCTIVITY ONE 

13.46 

TASKS/MAN-DAY 


COMPLETION TIME TWO 

429.50 

DAYS 


TOTAL EFFORT TWO 1 

,934.28 

MAN-DAYS 


QA EFFORT TWO 

500.57 

MAN-DAYS 

.26 

DEVELOP EFFORT TWO 

872.03 

MAN-DAYS 

.45 

REWORK EFFORT TWO 

259.70 

MAN-DAYS 

.13 

TESTING EFFORT TWO 

241.36 

MAN-DAYS 

.12 

TRAINING EFFORT TWO 

60.63 

MAN-DAYS 

.03 

OVERALL-PRODUCTI/ITY TWO 

12.61 

TASKS/MAN-DAY 


NET TRANSFERS 2 TO 1 

6.38 

MEN 


NET TRANSFERS 1 TO 2 

- 6.38 

MEN 


TOTAL EFFORT - BOTH 3 

,746.54 

MAN-DAYS 



Figure 87. Simulation 10—Statistical Results 
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DAYS 
























one's. The results of the simulation are presented in 
Figures 90, 91, and 92. 

12. TWRL2Tla and TWRLlT2a 

The manager's willingness to rely on the release of 
people from a completing project and its equivalent in the 
other project are the independent variables in this 
simulation (TWRL2T1 and TWRL1T2). This willingness is a 
ratio of the time remaining (for the completing project) to 
the hiring delay; the higher the ratio, the less apt the 
manager is to wait in the baseline scenario. In this 
simulation, this willingness was increased, from 
1/.5/.25/.1/0/0, the default values, to l/l/l/l/l/l. This 
increase simulates a manager who is always willing to rely 
on release of personnel from the other project regardless of 
how much longer it has before completion. Figures 93, 94, 
and 95 provide results. 

13. TWRL2Tlb and TWRLlT2b 

Once again, the manager's willingness to rely on the 
release of people from a completing project is the 
independent variable. However, in this case, this 
willingness was decreased from the default values given in 
the description of simulation 12 to 0/0/0/0/0/0. This 
decrease causes the situation in which the manager will 
never rely on people from the other project based on its 
completion. Figures 96, 97, and 98 are relevant. 
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PROJECT STATISTICS: 


PORTION OF 
TOTAL EFFORT 


COMPLETION TIME ONE 


414.50 

DAYS 


TOTAL EFFORT ONE 

1 

,845.46 

MAN-DAYS 


QA EFFORT ONE 


421.45 

MAN-DAYS 

.23 

DEVELOP EFFORT ' 

ONE 

884.99 

MAN-DAYS 

.48 

REWORK EFFORT ONE 

265.83 

MAN-DAYS 

. 14 

TESTING EFFORT ' 

ONE 

248.51 

MAN-DAYS 

. 13 

TRAINING EFFORT 

ONE 

24.68 

MAN-DAYS 

.01 

OVERALL-PRODUCTIVITY 

ONE 

13.22 

TASKS/MAN-DAY 


COMPLETION TIME TWO 


440.50 

DAYS 


TOTAL EFFORT TWO 

1 

,944.64 

MAN-DAYS 


QA EFFORT TWO 


500.89 

MAN-DAYS 

.26 

DEVELOP EFFORT 

TWO 

875.79 

MAN-DAYS 

.45 

REWORK EFFORT TWO 

257.95 

MAN-DAYS 

. 13 

TESTING EFFORT 

TWO 

260.37 

MAN-DAYS 

.13 

TRAINING EFFORT 

TWO 

49.64 

MAN-DAYS 

.03 

OVERALL-PRODUCTIVITY 

TWO 

12.55 

TASKS/MAN-DAY 


NET TRANSFERS 2 TO 1 


- 3.28 

MEN 


NET TRANSFERS 1 TO 2 


3.28 

MEN 


TOTAL EFFORT - BOTH 

3 

,790.10 

MAN-DAYS 



Figure 90. Simulation 11—Statistical Results 
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PROJECT STATISTICS; 


PORTION 

OF 



TOTAL EFFORT 

COMPLETION TIME ONE 

446.00 

DAYS 


TOTAL EFFORT ONE 1 

,791.38 

MAN-DAYS 


QA EFFORT ONE 

406.51 

MAN-DAYS 

.23 

DEVELOP EFFORT ONE 

880.55 

MAN-DAYS 

.49 

REWORK EFFORT ONE 

259.40 

MAN-DAYS 

.14 

TESTING EFFORT ONE 

244.11 

MAN-DAYS 

. 14 

TRAINING EFFORT ONE 

.81 

MAN-DAYS 

.00 

OVERALL-PRODUCTIVITY ONE 

13.62 

TASKS/MAN-DAY 


COMPLETION TIME TWO 

439.00 

DAYS 


TOTAL EFFORT TWO 1 

,919.22 

MAN-DAYS 


QA EFFORT TWO 

494.75 

MAN-DAYS 

.26 

DEVELOP EFFORT TWO 

867.90 

MAN-DAYS 

.45 

REWORK EFFORT TWO 

258.23 

MAN-DAYS 

.13 

TESTING EFFORT TWO 

238.29 

MAN-DAYS 

. 12 

TRAINING EFFORT TWO 

60.05 

MAN-DAYS 

.03 

OVERALL-PRODUCTIVITY TWO 

12.71 

TASKS/MAN-DAY 


NET TRANSFERS 2 TO 1 

20.12 

MEN 


NET TRANSFERS 1 TO 2 

- 20.12 

MEN 


TOTAL EFFORT - BOTH 3 

,710.61 

MAN-DAYS 



Figure 93. Simulation 12—Statistical Results 


118 











-SCHC1)I(CHI)(0.,8C0.) -TOIHF{ONE)(0.,«.) 

8C3,-SCHCM(IMO)(0.,8C'0.) .TOIltf(IHO)(0.,40.) 


800. 

30 


Z 

I 

e !B. 

Q 


200 . 

10 . 










_ ^ 



ICHCCT (OKEI 


m 

'V' 

/ 

1 


MtS 

1 

TOW 

I- . 

i .•-••••* 

TOWf (ONE) ^ 



1 


0 . 


1C3. 


ECO. 3£0. 

DAYS 


4ca. 


Figure 94. Simulation 12—Graph 1 
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Figure 95. Simulation 12--Graph 2 
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PROJECT STATISTICS: 


PORTION OF 
TOTAL EFFORT 


COMPLETION TIME ONE 

467.00 

DAYS 


TOTAL EFFORT ONE 1 

,847.37 

MAN-DAYS 


QA EFFORT ONE ■" 

454.38 

MAN-DAYS 

.25 

DEVELOP EFFORT ONE 

864.41 

MAN-DAYS 

.47 

REWORK EFFORT ONE 

256.28 

MAN-DAYS 

.14 

TESTING EFFORT ONE 

238.44 

MAN-DAYS 

.13 

TRAINING EFFORT ONE 

33.85 

MAN-DAYS 

. 02 

OVERALL-PRODUCTIVITY ONE 

13.21 

TASKS/MAN-DAY 


COMPLETION TIME TWO 

408.50 

DAYS 


TOTAL EFFORT TWO 1 

,935.44 

MAN-DAYS 


QA EFFORT TWO 

494.27 

MAN-DAYS 

.26 

DEVELOP EFFORT TWO 

874.58 

MAN-DAYS 

.45 

REWORK EFFORT TWO 

263.04 

MAN-DAYS 

.14 

TESTING EFFORT TWO 

234.08 

MAN-DAYS 

.12 

TRAINING EFFORT TWO 

69.46 

MAN-DAYS 

.04 

OVERALL-PRODUCTIVITY TWO 

12.61 

TASKS/MAN-DAY 


NET TRANSFERS 2 TO 1 

11.12 

MEN 


NET TRANSFERS 1 TO 2 

- 11.12 

MEN 


TOTAL EFFORT - BOTH 3 

,782.80 

MAN-DAYS 



Figure 96. Simulation 13—Statistical Results 
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Figure 97. Simulation 13—Graph 1 



DAYS 

Figure 98. Simulation 13—Graph 2 



















14. Sunuttarv 


One of the simulations of interest in experiment set 
three is simulation four in which the workforce ceiling 
allocation policy is changed from 50:50 to one in which the 
project with priority, project one, is able to hire up to 
the workforce ceiling. Project two can only hire if project 
one's hiring does not reach the ceiling. This simulation is 
of interest when compared to its equivalent in experiment 
set two xn which costs skyrocketed when this variable was 
changed. This does not happen in experiment set three. The 
explanation for this is that in experiment set three, 
project two has started first with project one starting at 
time 100. Until project one starts, project two is able to 
acquire and assimilate new workers early in its development. 
This leads to increased productivity over the life of 
project two. The result of this increased productivity is 
less difference in cost between this simulation and the 
baseline than was seen in experiment set two. 

This type of analysis, in which results of 
simulations are compared across experiment sets, is one area 
which warrants more attention. Also of import is analysis 
of the results within this experiment set. The analysis 
will provide more understanding of the complex and 
interrelated variables affecting software project 
management. 
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V. CONCLUSIONS AND SUGGESTIONS FOR FURTHER RESEARCH 


A. CONCLUSIONS 

The primary objective of this thesis, to extend the 
System Dynamics model of software project management to a 
multiproject environment, has been met. The extended model 
includes changes which were relatively narrow in scope, such 
as the addition of the start date variable and the addition 
of arrays. It also includes major changes to the human 
resource management subsystem. Identification and addition, 
of variables to reflect the considerations managers must 
ponder when determining how and in what numbers to transfer 
people as well as those variables necessary to maintain 
organizational balance provided insight into the mechanisms 
of human resource management. Chapter III is devoted to an 
explanation of these insights. Work in this area provided 
the information identified under the second of the three 
items listed in the "Thesis Objectives" section in Chapter 
II. 

The first item identified in that list, that of gleaning 
information on the effects of management manpower decisions 
on the allocation of resources to different projects, was 
addressed in the experiment sets described in Chapter IV. 

It becomes obvious that the way in which manpower is 
allocated within an organization and transferred between 
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projects impacts greatly on the combined cost of the 
projects. The experiments run with, for example, changes to 
the nominal ceiling on the workforce (NCLTWF) and to the 
workforce ceiling allocation policy (POLCYl) illustrate this 
point. 

The last item listed in Chapter II was that of gaining 
insights on optimizing the staffing function in a 
multiproject environment. Again, the experiment sets 
presented in Chapter IV, particularly the first set, provide 
information in this area. Of interest is the fact that how 
priority is set, dynamically or statically, and what project 
has priority affects the optimal overlap to minimize cost. 
There is no one optimal overlap for all situations—it is 
dependent on the various factors relevant to any software 
development situation. Comparison of the results in 
experiment set two and three and comparisons between the two 
experiment sets also provide insight into optimizing the 
staffing function. Of interest in regard to optimization of 
the staff function are those variables which, when changed, 
cause little or no change in the cost of the projects. This 
result indicates that those variables, such as hiring and 
transferring aggressiveness (TAGRSV) in experiment set two, 
do not affect costs and should therefore not be an item of 
concern to managers. 
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B. SUGGESTIONS FOR FURTHER RESEARCH 


This thesis provides a starting point for further 
research areas in several arenas. One of those is 
development of an expert system to automatically provide the 
manager with the optimal overlap to minimize cost given a 
certain scenario. The results presented in experiment set 
one were manually attained—a process no software project 
manager would have the time or inclination to undertake. 

Another area for further research is expansion of this 
new model to model environments in which more than two 
projects are underway. Though much of the initial work in 
that realm has been completed in this thesis, the real 
possibility of the identification of other variables 
affecting manpower decisions in this type of environment 
exists. 

Perhaps the most interesting area of further research in 
this arena is analysis of the results presented in this 
thesis. Of particular interest are the effects of changing 
the workforce ceiling and the effects of changing the hiring 
and transfer aggressiveness in experiment set one. In 
experiment set two, the cause of the drastic increase in 
cost when the workforce allocation policy is changed is an 
area for detailed analysis. The lack of a similar spike in 
experiment set three is also of ii't^rest. Discussions with 
software project managers and extens’’.'e research in the 
software project management field would be necessary to 
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explain and understand these results as presented in Chapter 
IV. This research could lead to identification of other 
variables of interest and further refinement of this model. 
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APPENDIX 


SUMMARY RESULTS OF EXPERIMENT SET ONE 


BASELINE SUMMARY RESULTS 


Overlap 

Cost 

Project 1 

— 

Cost 

Project 2 

Total Cost 

0 

1823.02 

1868.73 

3691.75 

20 

1889.03 

1872.55 

3761.58 

40 

1930.09 

1911.51 

3841.60 

60 

1981.93 

1933.09 

3915.02 

80 

2042.72 

1940.13 

3982.85 

100 

2028.94 

1922.49 

3951.43 

120 

2017.60 

1912.12 

3929.72 

140 

1995.47 

1901.36 

3896.83 

160 

1996.06 

1934.22 

3930.28 

180 

1851.63 

1934.56 

3786.19 

200 

1894.76 

1958.21 

3852.97 

300 

1809,83 

1954.88 

3764.71 

400 

1828,68 

1954.80 

3783.48 
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TRANSFER PRODUCTIVITY SUMMARY RESULTS 


Overlap 

Cost 

Project 1 

— 

Cost 

Project 2 

Total Cost 

0 

1830.62 

1875.15 

3705.77 

20 

1925.49 

1876.01 

3801.50 

40 

1974.57 

1903.59 

3878.16 

60 

2021.36 

1936.28 

3957.64 

80 

2079.04 

1950.11 

4029.15 

100 

2070.94 

1937.74 

4008.68 

120 

2060.92 

1907.59 

3968.51 

140 

2042.19 

1916.54 

3958.73 

160 

2050.45 

1929.13 

3979.58 

180 

1854.15 

1915.05 

3769.20 

200 

1864.97 

1949.45 

3814.42 

300 

1803.54 

1954.96 

3758.50 

400 

1829.16 

1954.80 

3783.96 
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WORKFORCE CEILING SUMMARY RESULTS 


Overlap 

Cost 

Project 1 

Cost 

Project 2 

Total Cost 

0 

1886.37 

1877.54 

3763.91 

20 

1906.43 

1896.12 

3802.55 

40 

1944.19 

1902.30 

3846.49 

60 

1951.44 

1898.79 

3850.23 

80 

1926.71 

1900.11 

3826.82 

100 

1914,38 

1903.10 

3817.48 

120 

1914.46 

1902.29 

3816.75 

140 

1900.24 

1925.89 

3826.13 

160 

1916.09 

1922.27 

3838.36 

180 

1877.10 

1919.80 

3796.90 

200 

1833.97 

1922.21 

3756.18 

300 

1784,05 

1903.45 

3687.50 

400 

1779.82 

1903.24 

3683.06 



























































WORKFORCE CEILING AND ALLOCATION SUMMARY RESULTS 


Overlap 

Cost 

Project 1 

— 

Cost 

Project 2 

Total Cost 

0 

1861.66 

1853.74 

. 

3715,40 

20 

1845.11 

1862.71 

3707.82 

40 

1865.97 

1883.68 

3749.65 

60 

1879.48 

1896.63 

3776.11 

80 

1874.08 

1899.39 

3773.47 

100 

1889.40 

1910.62 

3800.02 

120 

1897.66 

1918.52 

3816.18 

140 

1921.20 

1912.20 

3833.40 

160 

1840.53 

1874.45 

3714.98 

180 

1830.52 

1891.50 

3722.02 

200 

1842.35 

1908.62 

3750.97 

300 

1962.25 

1987.12 

3949.37 

400 

1856.66 

2030.46 

3887.12 
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HIRING AND TRANSFERRING AGGRESSIVENESS SUMMARY RESULTS 


Overlap 

Cost 

Project 1 

Cost 

Project 2 

Total Cost 

0 

1920.76 

1904.95 

3825.71 

20 

1944.36 

1901.39 

3845.75 

40 

2006.75 

1930.78 

3937.53 

60 

2084.35 

1947.30 

4031.65 

80 

2135.07 

1955.63 

4090.70 

100 

2116.13 

1937.46 

4053.59 

120 

2023.54 

1914.06 

3937.60 

140 

2047.54 

1907.27 

3954.81 

160 

2112.06 

1901.34 

4013.40 

180 

1876.49 

1950.46 

3826.95 

200 

1932.36 

1977.71 

3910.07 

300 

1816.91 

1962.76 

3779.67 

400 

1842.20 

1962.75 

3804.95 
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PROJECT STARTING FIRST HAS PRIORITY SUMMARY RESULTS 


Overlap 

Cost 

Proj ect 1 

Cost 

Project 2 

Total Cost 

0 

1810.49 __ 

2025.21 

3835.70 

20 

1803.50 

2044.93 

3848.43 

40 

1813.53 

2107.38 

3920.91 

60 

1829.74 

2083.19 

3912.93 

80 

1840.69 

1906.84 

3747.53 

100 

1852.70 

1838.67 

3691.37 

120 

1863.02 

1827.91 

3690.93 

140 

1885.53 

1820.44 

3705.97 

160 

1904.28 

1828.84 

3733.12 

180 

1934.56 

1851.63 

3786.19 

200 

1958.21 

1894.76 

3852.97 

300 

1954.88 

1809.83 

3764.71 

400 

1954.80 

1828.68 

3783.48 
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PROJECT STARTING LAST HAS PRIORITY SUMMARY RESULTS 


Overlap 

Cost 

Project 1 

Cost 

Project 2 

Total Cost 

0 

1810.49 

2025.21 

3835.70 

20 

1805.90 

2013.98 

3819.88 

40 

1825.74 

2010.19 

3835.93 

60 

1837.31 

1967.22 

3804.53 

80 

1841.82 

1949.91 

3791.73 

100 

1845.33 

1944.72 

3790.05 

120 

1859.30 

1945.46 

3804.76 

140 

1845.87 

1948.48 

3794.35 

160 

1849.84 

1950.32 

3800.16 

180 

2050.06 

1909.19 

3959.25 

200 

1958.82 

1904.26 

3863.08 

300 

1809.83 

1954.88 

3764.71 

400 

1828.68 

1954.80 

3783.48 
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